Docker Kata 2: Disconnected Containers

The first kata demonstrated containers that exit immediately after they’re run. This kata will teach us how to run a container that continues running in the background after executing the docker container run command.

Step 1: Run a disconnected container#

The command to run a disconnected container in the background is given below.

The output will be something like this:

This step demonstrates how Docker can run a disconnected container in the background. Running a disconnected container is essentially the opposite of running it interactively. A disconnected container will run without user input or interaction as long as its start process runs.

This command does the following:

• Runs a disconnected Ubuntu container
• Specifies the command to run after the image name
• Uses /bin/sh to run the sh shell, which runs scripts in the bash command language
• Executes the inline script: "while true; do echo hello docker; sleep 1; done"

When this command is run, there’s one output, which is the ID of the started container. The Unix shell program bin/sh acts as the start command. The inline script is run by the sh program. Remember, the container will only run as long as the start command runs. The script in this command runs indefinitely, so the container will never stop on its own. This demonstrates a script that will keep a container running; however, it’s not very practical. The next kata will demonstrate a more useful long-running disconnected container.

The command to list the running containers is given below.

When we run the command above, we’ll see the following output:

The command docker container ls lists the running containers. Note that the container ID in the list matches the ID in the output from the first command.

The command to output the logs of the container is given below.

The output of the command above will be something like this:

The docker container logs ＄(docker container ls -q) command outputs the logs of the Ubuntu container. When commands and programs are run in Unix, the output we see in the terminal window is called STDOUT (standard out) output. Commands and programs that are run in a container output to STDOUT. This output is saved in the container log. The output of this command is hello docker, repeated several times. The echo command in the script sends hello docker to STDOUT once per second for as long as the container continues to run. The logs of a container are used to monitor the output of the process running inside the container.

The command to stop the containers is given below.

We’ll see something like this when we run the command above:

The docker container stop ＄(docker container ls -q) command stops the container. This sends a signal (SIGTERM, in Unix parlance) to the container. The process running inside the container receives this signal and, if it supports the SIGTERM signal, gracefully shuts itself down. Linux programs that support SIGTERM will gracefully release resources and terminate themselves when they receive the SIGTERM signal from the OS. If the process doesn’t respond to SIGTERM, Docker will wait for a timeout period, then send SIGKILL, which forces the container process to terminate.

Step 2: Execute commands on a running container#

The command to run a container from the NGINX image is given below.

The output will be something like this:

This step runs a container from the NGINX image. NGINX is an open-source HTTP server. The nginx container on Docker Hub is provided by NGINX Inc., maker of NGINX. It’s configured to start the NGINX web server when the container starts.

The command to list the files and directories in the container is given below.

When we run the command above, the output will be something like this:

This step executes a command in the running container. The ls command lists the files and directories in the root directory of the container.

The commands to obtain network configuration information are given below:

We’ll see something like this when we run the command above:

The ip addr command returns the detailed network configuration information from the container.

The command to run lines including the specific text is given below.

The output of the command will be something like this:

Linux commands, in general, and Docker commands, in particular, often return a lot of information. The grep program provides an easy way to filter that information. The pipe | redirects the output of ip addr to grep:

ip addr | grep inet

The effect of this command is to return only lines that include the text inet. This method can be used to filter command output, displaying data relevant to the task at hand.

Step 3: Connect interactively to a running container#

The command to connect interactively to a running container is given below.

When we run the these commands line by line, the output will be something like this:

This step is similar to the command in Kata 1 Step 5:

docker container run -it ubuntu bash

The difference in this command is that it runs the bash command on a disconnected container that’s already running. If we run docker container ls, we’ll notice another difference. The container has not exited; it will still be running. The NGINX container’s start process is the NGINX HTTP server, not the bash process we started with the exec command. Exiting the bash process doesn’t stop the container because the HTTP server process is still running.

Practice commands#

We’ve given a terminal and a table containing a list of commands discussed in this lesson. Try out these commands after running the terminal, and check out the results!